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ABSTRACT 

This paper offers several contributions for separation of duty 
(SoD) administration in role-based access control (RBAC) 
systems. We first introduce a new formal framework, based 
on business perspective, where SoD constraints are analyzed 
introducing the activity concept. This notion helps organi- 
zations define SoD constraints in terms of business require- 
ments and reduces management complexity in large-scale 
RBAC systems. The model enables the definition of a wide 
taxonomy of confiict types. In particular, object-based SoD 
is introduced using the SoD domain concept, namely the set 
of data in which transaction confiicts may occur. Together 
with the formalization of the above properties, in this pa- 
per we also show the effectiveness of our proposal: we have 
applied the model to a large, existing organization; results 
highlight the benefits of adopting the proposed model in 
terms of reduced administration cost. 

1. INTRODUCTION 

Role-based access control (RBAC) [2] is a well known and 
recognized good security model for enterprise access control 
management. Central to the model is the role concept (a set 
of access permissions) with users assigned to roles based on 
duties to fulfil. One of the main benefits related to adopting 
the RBAC model is the abstraction level introduced by a 
role. Roles help organizations manage complex structures 
and large number of identities and permissions within their 
IT systems. Indeed, a role represents an intermediate layer 
between permissions (typically managed by IT staff) and 
users (typically managed by business staff). This helps or- 
ganizations prevent users from accessing information at their 
own discretion. In this sense, the role is a business concept 
although not the only one to be considered when addressing 
access control. Other business elements, such as business 
processes or organization structure, should be included in 
the overall access control model. To date only a few im- 
plementations extend the RBAC model with other business 
properties. 

Another important benefit related to RBAC is represented 
by its simple security administration. RBAC is universally 
recognized as a policy-neutral access control model in the 
sense that using hierarchies and constraints, a wide range of 
security policies can be expressed, including discretionary 
access control (DAC), mandatory access control (MAC), 
and user-specific access control [6, 14]. Among all possi- 
ble aspects of security policy, separation of duty (SoD) is 
probably the most important. Alternatively indicated as 
"conflict of interest" or "mutual exclusion", SoD usually 



refers to the identification of operations which should not 
be granted to an individual user. For instance, an employee 
acting as a financial manager may not be allowed to act 
as a financial auditor at the same time. There are several 
types of frameworks proposed in literature for SoD adminis- 
tration [1,4, 7, 9, 10, 17, 18, 20, 21]. Nevertheless, when thou- 
sands of users, roles, and permissions have to be managed, 
such frameworks do not scale well, so that administering 
SoD in large-scale RBAC systems is still quite challenging. 
Moreover, existing frameworks do not leverage business ele- 
ments to simplify the SoD administration in complex envi- 
ronments. 

This paper describes a new framework for administer- 
ing separation of duty constraints, particularly suitable for 
large-scale RBAC systems. The framework is based on the 
following steps: first, the business processes are decomposed 
into business activities; this may be entirely done by busi- 
ness staff. Then, access permissions supporting all the ac- 
tivities are identified by IT staff. Potential confiicts among 
activities are also provided, again by business staff, leverag- 
ing a business perspective. Such information is used to com- 
pute conflicts among RBAC entities — permissions, roles and 
users. We show how the proposed model offers a natural way 
to define SoD constraints and to reduce management com- 
plexity in large-scale RBAC systems. The proposed model 
allows a wide taxonomy of conflict types; in particular, we 
introduce the SoD domain concept as the set of data in 
which transaction conflicts may occur. Introducing SoD do- 
mains makes it possible to easily deflne more expressive con- 
straints such as object-based separation of duty. Finally, we 
have applied the proposed model on real data from a large 
organization. Results conflrm that our proposal greatly re- 
duces the administration cost required to manage RBAC 
systems. 

The remainder of the paper is organized as follows: Sec- 
tion[2]offers a survey of state of the art as for SoD constraint 
and role administration techniques. Section [3] summarizes 
the main RBAC concepts needed to formally analyze the 
problem. Section U provides a theoretical analysis of the 
problem, introducing both the activity and the SoD domain 
concepts. Section[S]offers a trivial usage example of the pro- 
posed model. Section[6]shows an application of the model to 
a large, actual organization. Finally, Section [7] offers some 
flnal considerations. 

2. RELATED WORK 

Separation of privilege is one of the founding principles 
for the protection of information according to Saltzer and 



Schroeder [16] . Further, Clark and Wilson [3] identified sep- 
aration of duty as one of the two major mechanisms that 
can be implemented to ensure data integrity. At the policy 
level, processes can be divided into steps, with each step 
being performed by a diflFerent agent. 

Several attempts to formally define separation of duty 
constraints can be found in literature, especially in role- 
based access control [4,9,17,18]. Simon and Zurko [20] pro- 
vide a comprehensive classification, enumerating the diflFer- 
ent kinds of confiicts. Kuhn [7] proposes mutual exclusion of 
roles as a separation of duty mechanism; SoD requirements 
are categorized according to the time mutual exclusion is 
applied. Also Nyanchama and Osborn [10] describe a way 
to implement various types of confiicts; they evaluate the 
effect of role hierarchies in terms of their role-graph model. 
Ahn and Sandhu [1] define the RSL99 language for specify- 
ing separation of duty constraints. 

All the aforementioned works are mainly based on the 
core RBAC entities, namely permissions, roles, sessions, and 
users, missing other business elements. Yet, since SoD is a 
business requirement, other business aspects affecting SoD 
are expected to be identified. For instance, although a user's 
privileges are often granted based on the tasks the user is 
expected to fulfill, the concept of tasks is usually not explic- 
itly modeled in access control [5]. Perelson and Botha [15] 
provide a solution for the specification of static separation 
of duty requirements in role-based workfiow environments. 
The authors identify the impact of SoD on work process 
models. Then they extend the typical RBAC model to in- 
clude the notion of task. Although tasks are taken into 
consideration during conflict analysis, they are not used as 
elements for defining conflicts. Likewise, Irwin et al. [5] in- 
troduce the task concept as a means to determine users' 
privileges and use tasks to define some security properties. 
Other works attempt to highlight the importance of business 
information in role-based access control, but they princi- 
pally address role administration and definition, not always 
considering SoD. For example, Oh and Park [12] highlight 
how, in real implementations, users must have permissions 
to complete a task. Their T-RBAC model [11] is an example 
of RBAC extension that introduces "task" as a business con- 
cept. Schaad and Moffett [19] propose the Alloy language 
to model organizational control principles, such as those ex- 
pressed in separation of duty, supervision and delegation. 
While other important frameworks for administering RBAC 
systems strive to include business elements as well [10,13,22], 
SoD administration based on a modeling of business is not 
always provided. 

3. BACKGROUND 

This section offers some of the concepts in the RBAC 
model [2] that will be used in the following. The entities of 
interest for the present analysis are: 

• PERMS, the set of all possible access permissions; 

• USERS, the set of all system users; 

• ROLES C 2™^*^''', the set of all roles; 

• UAC USERS X ROLES, the set of all role-user rela- 
tionships; 

• PA C PERMS X ROLES, the set of all role-permission 
relationships; 

• RH C ROLES X ROLES, the set of hierarchical rela- 
tionships between roles. 



The symbol ">;" indicates an ordering operator representing 
a path of direct relationships in RH. If ri >r r2, then ri is 
referred to as the child or the senior of r2. Similarly, is 
the parent or the junior of ri . 

The following functions are also provided: 

ROLES 2^^^^*^ to identify users assigned 
to a role and to none of its senior roles, according to 
UA. 

• ass_users*: ROLES 2^*™* to identify users assigned 
to a role or to at least one of its seniors, according to 
UA and RH. 



ass-perms: ROLES — > 2 



PERMS 



to identify permissions 



assigned to a role and to none of its senior roles, ac- 
cording to PA. 
• ass.perms* : ROLES 2™^-*''^ to identify permissions 
assigned to a role or to at least one of its seniors, ac- 
cording to PA and RH. 

In applying dynamic security policies, the session concept 
should be taken into account. Each session identifies the set 
of active roles for a given user. A user may be associated 
with multiple sessions at any moment in time. This fea- 
ture supports the principle of least privilege; that is, a user 
assigned to multiple roles may activate any subset of these 
roles to perform his/her tasks. This may be used in support 
of dynamic separation of duty policies. According to the 
RBAC standard, the function session^roles : SESSIONS —> 
2ROLES j(jgjj^jfjgg ^jjg Qf active roles for the user associated 
to the given session. 

Finally, note that according to the standard, a permis- 
sion is an abstract concept that refers to the arbitrary bind- 
ing of operations and objects. This means that elements 
of PERMS are actually pairs (o, m) , where £ OBJS indi- 
cates the object and m £ OPS the way in which the object is 
accessed — where OBJS and OPS indicate, respectively, the 
set of objects and operations monitored by the access con- 
trol system. In this paper permissions are always considered 
as a single unit, except when referred to SoD domains (see 
Section [4. 4|l . where objects are used to group permissions. 

4. MODEL DEFINITION 

This section illustrates a new SoD model, where confiicts 
are not directly defined among permissions or roles, but 
among business activities. The rationale is that large com- 
panies typically have hundreds of thousands of permissions 
and roles, while possessing only a few hundred activities. 
Therefore, managing activities is often easier than manag- 
ing other RBAC entities. Tasks are a natural way to think 
about user actions and their contexts [5] , making the identi- 
fication of users performing conflicting activities more intu- 
itive than the identification of users assigned to confiicting 
roles or possessing conflicting permissions. 

Most of the existing SoD models are characterized by 
defining confiicts among permissions or roles. For instance, 
Kuhn [7] proposes mutual exclusion of roles (i.e., roles which 
should not be simultaneously assigned to a user) as a separa- 
tion of duty mechanism. But defining SoD conflicts among 
roles could lead to inconsistent constraint definitions. This 
is because user's capabilities are vested in permissions, not 
roles. For instance, suppose we have roles ri, r2, and rs 
where only ri and r2 are specified as being mutually ex- 
clusive. However, r2 and 7-3 might be assigned with the 
same permission set (i.e., ass_perms* (r2) = ass_perms* (ra)) 



or, more generally, they might share the same permissions 
which generate conflicts with role n (i.e., capabilities pro- 
vided by ass_pcrms'' (r2)nass_pcrms* (r-^) arc conflicting with 
capabilities provided by ass.pcrms* {r i)) . According to this 
observation, both pairs {ri,r2} and {ri,r3} would provide 
a user with the same conflicting permissions. While no user 
could be assigned to both ri and r2 at the same time, a user 
could be simultaneously assigned to ri and rs since these are 
not defined as conflicting at the role level, tough providing a 
user with equal conflicting permissions. This illustrates how 
defining conflicts among roles can easily lead to ill-defined 
SoD constraints or, even worse, allows to entirely bypass 
other constraints. 

According to the previous observation, the correct ap- 
proach should be to define conflicting permissions, namely 
sets of permissions which should not be simultaneously pos- 
sessed by the same user. If permission conflicts are known, 
it will be possible to deduce role conflicts: conflicting roles 
would be those having conflicts in the union of their assigned 
permissions. Therefore, specifying conflicts among permis- 
sions provides a finer grarmlarity as opposed to specifying 
conflicts at the role level. Yet, in large organizations there 
could be hundreds of thousands of permissions, leading to an 
unmanageable situation. Besides this, it is usually difficult 
to find a user within the organization who has both the busi- 
ness and the IT knowledge required to identify confiicting 
permissions. 

In order to reduce complexity of SoD constraint descrip- 
tion, we propose an alternative approach where conflicts are 
not directly defined among permissions or roles. Before ex- 
plaining how the proposed model addresses this problem, it 
is necessary to introduce the activity concept. 

4.1 Business Activities 

Activities are identified by decomposing business processes 
of an organization. From an access control point of view, an 
activity is a set of permissions necessary to perform a cer- 
tain task. In this sense, the activity and role concepts are 
similar in that they both group permissions, but do have 
some important differences: 

• Meaning. Roles group permissions to be assigned to 
a user in order to support the work he/she has to do, 

but do not always directly map to specific business ac- 
tivities. Some roles having no business meaning could 
simply be defined out of convenience. For example, 
when the hierarchical RBAC model is adopted, a so 
called "connector role" represents the intersection of 
permissions assigned to all the derived roles; but the 
connector role may have no business meaning. Ad- 
ditionally, some RBAC implementations offer a way 
to define IT and business roles. Business roles are 
typically established by the business (e.g.. Employee, 
President, Trader, etc.) whereas IT roles are estab- 
lished by the application owners (e.g., admin, user, 
auditor, etc.). In these systems, it is expected that 
mapping business roles to IT roles would simplify pol- 
icy specification. In such case, IT roles exist only to 
reduce the overall system administration effort, while 
business roles could allow to perform more than one 
business activity. 

• Cardinality. A typical large-scale organization could 
have thousands of roles defined in its access control 
system, while having no more than a few hundred busi- 



ness activities. In any organization, activities depend 
on company objectives, not organizational structure 
or hcadcount. For instance, suppose two sales man- 
agement roles na_sales_mgr and emea_sales_mgr are 
assigned different permission sets as they are related 
to different markets. Despite the need for two distinct 
roles, they likely allow the same kind of activities to be 
performed. While new roles are created in response to 
new sales markets, no new activities will be required. 
Thus, working with activities instead of roles (when- 
ever the problem permits this replacement) allows an 
organization to better address its growth. 

• Abstraction. A role is defined to manage permissions, 
while an activity is a business concept independent 
from permissions. Activity constraints could be identi- 
fied by business staff who have no knowledge of access 
control. Instead, the role constraint definition could 
require a joint effort between business and IT. 

4.2 Activity Concept Formalization 

Activities are obtained by decomposing business processes 
into more elementary components, resulting in a tree struc- 
ture formally described as follows: 

• the set ACTVT contains all activities obtained by de- 
composing business processes; 

• the set ACTVT-H C ACTVT x ACTVT defines a par- 
tial order on the hierarchy tree; (ap,ac) £ ACTVT-H 
means that the activity ap is the parent of the activity 
Oc, also represented by Oc — > a^; 

• the activity tree has only one root; 

• Va G ACTVT, the activity a has only one direct par- 
ent, namely Vop,Oc £ ACTVT : Oc — > Op 
ACTVT, a'p ^ ap : ac ^ a'p. 

Activity hierarchy is described using the concept of gen- 
eralization, that is, using an "is-a" relation [8]. Given two 
activities Op,Oc £ ACTVT, then Gc "is-a" ap indicates that 
ttp is more general than ac. This relationship, represented 
with the notation Oc — > ttp, also defines a partial order; thus, 
ttc >: ap indicates the existence of a hierarchical relationship 
pathway of from Oc to ap. Note that, without loss of 
generality, it is always possible to individuate a unique root 
for a set of activities; for example, a virtual activity "col- 
lecting" all the high level activities of the organization could 
be always defined. 

Each activity is supported by sets of permissions, which 
allow activities to be performed. To obtain a greater level 
of fiexibility, the permission grouping concept has been in- 
troduced into the model. Instead of assigning permissions 
directly to activities, permissions are first grouped into one 
ore more subsets. For a user to perform a given activity, 
such user must have all the permissions associated to at 
least one activity-related grouping. This models situations 
where harmful activities are not defined by a single action. 
If a user is assigned all the permissions of a grouping, it is 
possible to assert that the user performs the activity associ- 
ated to such a grouping. More precisely, a set of permission 
groupings is attached to each activity and can be formalized 
as follows: 

• GRPS C 2™^** represents the possible permission 
groupings which can be assigned to activities. 

• ACTVT-G C ACTVT x 2'^'^^''' expresses the origin of 
a permission grouping in a given activity. 



The function actvt^rps: ACTVT -> 2^''*^^' provides the set 
of groupings associated to an activity. Given an activity 
a G ACTVT, it can be formalized as 

actvt^rps{a) ^ {g £ GRPS \ 3{a,g) G ACTVT-G}. 

The previous function can be extended to takes into account 
the activity breakdown structure, namely 

actvt.grps* (a) = {p G GRPS \ 3a' G ACTVT : aV a, 

(a, g) G ACTVT-G} 

provides all the groupings assigned to a and its children. 

Notice that activities and groupings can be seen as special- 
ization of roles. In particular, assume the role entity is en- 
riched with a new attribute making a distinction among reg- 
ular roles, activities, and groupings. Therefore, ACTVT C 
ROLES and GRPS C ROLES, ensuring that elements in 
ACTVT and GRPS are unassignable. Similar to users as- 
signed to hierarchical-related roles, a user performing an ac- 
tivity could also perform all parent activities in the activity 
tree. Moreover, the set PA will be used to assign permissions 
to groupings, while RH will be used to define the activity 
structure with groupings as leaves of the tree. Constraint 
formalization and mechanisms defined for roles may also be 
used among activities and groupings. 

The following sections formalize SoD confiicts within the 
model. Because of the analogy between roles and activities, 
such definitions can be directly derived from SSD (Static 
Separation of Duty) and DSD (Dynamic Separation of Duty) 
constraint definitions of [2]. 

4.3 Conflict Definition 

Potential SoD conflicts are identified among activities, 
namely from a business perspective. The set SoD-G C 
2ACTVT ^ describing activity confiicts, is a collection of 
pairs {A, n) where each A is an activity set, while n > 2. No 
user should perform more than n — 1 activities in A for each 
{A, n) G SoD-G. Since activities are hierarchically related, 
users should not perform neither activities in A nor parent 
activities of A. 

An observation key is that, since activities identify permis- 
sion sets, it is possible to derive conflicting permissions from 
conflicting activities. For example, let us assume the activi- 
ties "Invoice Creation" and "Invoice Approval" conflict; fur- 
ther, assume permissions {new_invl, new_inv2, new_inv3 } 
are needed to complete the activity "Invoice Creation" and 
{ app_invl, app_inv2 } to complete the activity "Invoice 
Approval". Thus, there should not be any user possess- 
ing permissions {new_invl, new_inv2, new_inv3, app_invl, 
app_inv2 } since these permissions allow users to perform 
conflicting activities, namely creating and approving an in- 
voice by oneself. Based on this observation, the following 
are different kinds of confiicts among RBAC entities that 
can be identified when adopting the proposed model. 

Conflicting and illegal permissions. Permissions conflict 
when they allow execution of conflicting activities. Formally, 
given a set P C PERMS, permissions in P conflict if the 
following holds: 

3(A,n) G SoD-G, 3A'c A : |A'| >n ^ 

Va G A', BP'CP : P' G actvt_grps* (a). (1) 



When \P\ = 1, the permission p G P is illegal, meaning that 
the permission allows the execution of conflicting activities 
by itself. This happens whenever an application does not 
allow the execution of different activities recurring to differ- 
ent functionalities (e.g., the application offers only one func- 
tionality for the "Invoice Creation" and "Invoice Approval" 
activities) . 

Conflicting and illegal roles. Roles are conflicting when 
the union of their assigned permissions allow execution of 
conflicting activities. Formally, given a set R C ROLES, 
roles in R conflict if the following holds: 

3{A,n) G SoD-G, 3A'C A : \A'\>n ^ 

Va G A', 3P'c [J^^^ ass_perins{r) : 

P' € actvt^rps'ia). (2) 

When |_R| = 1, the role r G J? is illegal, namely it con- 
tains conflicting or illegal permissions. In order to consider 
the role hierarchy. Equation [2] can be easily extended us- 
ing ass.perms* {r) instead of ass_perms{r) . Note that Equa- 
tion [2] is derived from Equation [T] by substituting the set of 
all conflicting permissions P with the union of permissions 
assigned to roles in R. 

Conflicting and illegal users. Users conflict when the 
union of permissions assigned to their roles allows execution 
of conflicting activities. Formally, given a set U C USERS, 
users in U conflict if the following holds: 

3{A,n) G SoD-G, 3A' C A : \A'\>n =^ 
Va G A', 3P' C I g^gy , us^s.uscrs(r) ass_perms{r) : 

P' e actvt_grps''{a). (3) 

When \U\ — 1, the user it G f/ is illegal, namely it is as- 
signed to conflicting or illegal roles. In order to consider 
the role hierarchy. Equation [3] can be easily extended using 
ass.perms* (r) instead of ass_perms(r), and ass.users* (r) in- 
stead of ass_users(r). Note that Equation [3] is derived from 
Equation [1] by substituting the set of all conflicting permis- 
sions P with the union of permissions assigned to users in 
U through their assigned roles. 

Equation [3] does not take into account sessions and can 
thus be used only for static SoD constraint definition. As far 
as dynamic SoD is concerned, given a session s G SESSIONS 
the previous equation can be modified as follows: 

3{A,n) G SoD-G, 3A' C A : jA'| > n ^ 

Va G A' 3P' C I J ^ , , , ass_nerms(r) : 

P' G actvt^rps* (a) . (4) 

According to the RBAC model, a session is related to a 
single user. In order to consider role hierarchy, the previous 
equation can be easily extended using ass_perms* (r) instead 
of ass_perms{r) . 

4.4 SoD Domains and Constraint Taxonomy 

The introduction of the activity concept allows flexible 
categorization of several kinds of SoD constraints. For ex- 
ample, the constraint taxonomy proposed in [20] can be ex- 
tended recurring to the activity concept instead of the role 



concept. The first class of constraints is represented by Op- 
erational SoD: activities, to be considered conflicting, must 
be completed in all their steps. Therefore, the users are 
allowed to execute parts of, but not the entire set of con- 
flicting activities. From an access control viewpoint, a step 
is no more than a set of permissions [11, 12]. In our model, 
this concept is mapped to permission groupings. If a partic- 
ular order of execution is required, dynamic session-based 
mechanisms might be implemented. 

Another SoD constraint class is represented by the Object- 
Based SoD specifying that a user cannot execute conflicting 
activities on the same object. This kind of constraint is 
usually not directly supported by RBAC implementations. 
To support it, we introduce the SoD domain concept in our 
model. For instance, a SoD domain is a set of data on which 
a single user should not complete conflicting activities. If 
a user can perform conflicting activities on different data, 
then it is probably impossible to configure an illegal action. 
A SoD domain can be a single row on a DBMS table, or 
simply the set of all data accessed by a given application. As 
mentioned in Section [S] a RBAC permission is represented 
by a couple (o, m), where o indicates the object and m the 
way in which the object is accessed. This means that given 
a permission, it is possible to determine in which domains 
the permission operates. Consequently, SoD domains can 
be formalized as follows: 

• SoD-D indicates the set of all SoD domains. 

• SoD-D-OBJS C SoD-D x 2°^'^*' expresses the origin of 
an object in a given SoD domain. 



The function perm_domains : PERMS 



r,SoD-D 



provides 



the set of SoD domains a given permission operates. This 
can be computed from the sets SoD-D-OBJS and PERMS; 
given p G PERMS the function can be defined as: 

perm_domains{p) — {d £ SoD-D \ 3{d,0) G 

SoD-D-OBJS, 3m e OPS, 3o e O : {o,m) = p}. 

To bring the SoD domain concept in the equations of the 
previous section, it is required that all conflicting permis- 
sions must be confined within the domains contained in set 
D. Therefore, Equation [1] (conflicting and illegal permis- 
sions) becomes 

3{A,n) e SoD-G, 3A'CA, 3D C (2*°-°\{0}) : \A'\ > n 
^ WaeA', 3P'CP : P' e actvt^ps'ia), 

ripgp' perm_doinains{p) = D. (5) 

Similarly, Equation [2] (conflicting and illegal roles) becomes 

3{A,n} e SoD-G, 3A' C A, 3D C (2*°-°\{0}) : \A'\ > n 
=^ Va £ a', 3P' C Urs-R 3ss_perms{r) : 
P' £ actvt^grps* (a) , f]^^p, perm_domains{p) = D. (6) 

Equation |3] (conflicting and illegal users without sessions) 
becomes 

3{A,n) G SoD-G, 3A' C A, 3D C (2'''°°-"\{0}) : \A'\>n 
=^ VaGA', aP'c U,|3„6C7:„6a.s.usors(r)ass.perms(r) : 
P'g actvt-grps* (a) , f]^^p, perm_domains{p) = D (7) 
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Figure 1: Graphical representation of the SoD 
model 



while Equation |4] (conflicting and illegal users with sessions) 

3{A,n) G SoD-G, 3A' A, 3D C (2*°"°\{0}) : \A'\ > n 

^ VaGA', 3P' C U,6,e.sio.^-ofc.(s) ass.perms(r) : 

P G actvt_grps*(a), f]^^p, perm_domains{p) = D. (8) 

Although defining SoD domains at the object level allows 
the finest granularity, the resulting complexity could be un- 
manageable, hence preventing its application. To dominate 
the curse of complexity, it is often sufficient to define a do- 
main as the set of all data accessed by an application or 
set of applications. Most of the time, using the applica- 
tion to identify data sets provides assurance that users are 
prevented from executing confiicting actions. It is impor- 
tant to highlight that different data does not necessarily 
mean different domains. In fact, the same data can belong 
to multiple SoD domains; moreover, working on one object 
can have effects over other related objects. For this reason, 
it would be too restrictive to say that permissions accessing 
distinct objects cannot cause conflicts between one another. 
Most of the time, deflning SoD domains as all data accessed 
by an application allows to correctly partition conflicting 
permissions. 

5. EXAMPLES 

This section introduces some examples illustrating prac- 
tical applications of the proposed SoD model. For this pur- 
pose. Figure [T] shows a possible model instance, depicting 
relationships among involved entities. It depicts some exam- 
ple permissions {PERMS — {pi, . . . ,P9}), roles {ROLES = 
{ri, . . . ,rg}) and the corresponding permission-role assign- 
ments. The "aggregation" concept is used to assign permis- 
sion sets to roles, while the "generalization" concept is used 
in defining hierarchical relationships. For example, role ri 



is a composition of permissions pi,P2, while role rg is a 
composition of permissions pi,p2,P3,p4, ps since it is senior 
of ri,r2,r3 from which it inherits permissions pi,p2,P4,P5- 
The figure also shows how permissions are entirely managed 
by IT staff, where role definition is a typical joint-task of 
both business and IT people (sometimes represented by a 
"security" staff). 

Permission groupings {GRPS = {gi,...,gs}) are sim- 
ply aggregation of permissions, while activities {ACTVT = 
{ai, . . . , aio}) inherit permissions from groupings or other 
activities. In the figure, activity a2 is performed when a 
user possesses permissions P2,P4 (i.e., grouping g2) or per- 
missions P3,P4, (i.e., grouping (73), namely actvt_grps(a2) — 
{92,93} = {{P2,P4}, {p3,P4}}. Instead, activity aio is per- 
formed when a user possesses pg (through the hierarchical 
relationship with or ae) or pg (directly through group- 
ing gr). In fact, permission ps allow not only execution of 
activities as, ae, but also activity aio. Similar to a role defi- 
nition task, security staff are in charge of defining permission 
groupings while activity tree identification is a typical task 
for business staff. 

Figure [T] shows two distinct domains {SoD-D = {di,d2}). 
For example, permission pe is declared to operate in both 
domains, that is perm_domains{p(i) — {di,d2}, while per- 
mission p2 operates in di but not in d2. Permission pi is not 
associated to any domain, thus it can never conflict with 
other permissions; in fact perm_domains(pi) = and any 
equation from Sections 14.31 and 14.41 could be satisfied. In 
the figure, si is a graphical representation of a possible SoD 
constraint in SoD-G, stating that activities a2,a4,aio can- 
not be performed by the same user at the same time. Ac- 
cording to Section [4.31 this can be formally represented by 
the pair {{a2, 04, aio}, 3). Again, we emphasize the fact that 
defining SoD constraints is a task for business staff. 

Ignoring the SoD domain concept, ({02, 04, aio}, 3) makes 
''2,f5,r8 confiict because of Equation [5] In fact, role r2 is 
assigned with permissions P2,P4, namely grouping g2, thus 
supporting activity 02. Role rs is assigned with permis- 
sions p7,ps,P9, namely groupings g(,,g7,gs, thus support- 
ing activities a5,a6,aio. Note that role rs allows partial 
execution of activity a4, since permission pe is needed to 
complete grouping gs. Thus, role rg is required to perform 
activity 04. Role rg is also assigned with permission ps (in- 
herited from role rs) thus allowing execution of activity 03, 
that has no influence on the analyzed SoD constraint. Per- 
missions p2 , P4 , P6 , P7 , P8 , P9 are thus conflicting and any user 
possessing them (i.e., roles r2, rs, rg) would be illegal. 

Introducing SoD domains, roles r2,rs,rg conflict in do- 
main di. In fact, permissions p2,P4,P6,P7,pg can operate 
in domain di, while pg cannot. Although activity aio is 
not directly supported by pg, both activity as and ae sat- 
isfy Equation [2] since as >r aio and ag >r aio. Similarly, 
roles rs , re , rg conflict in domain d2 . 

Note that role rg inherits permissions from r2,rg, thus 
roles rs,rg confiict. For the same reason, roles rs,r7,rg con- 
flict as well. If the previous SoD constraint is changed to 
({a2, a4, aio}, 2), role rg will be illegal. In fact, the con- 
straint requires only two activities to be performed, so that 
rs is no longer needed to support aio. Adding the con- 
straint ({as, ag}, 2), permission pg will also be illegal as well 
as role rs. 

6. TESTING ON REAL DATA 



A large private company has been analyzed to highlight 
the properties of the proposed SoD model. In particular, 
the analyzed RBAC system is composed up of 90,287 users, 
12,314 permissions (related to 67 different applications), and 
16,755 roles. 

In accordance to our framework, the business staff iden- 
tified an activity tree containing 298 nodes. Upon this tree, 
437 conflicting activity pairs were defined. To simplify the 
definition of conflicts, only conflicting activity pairs were 
considered, namely constraints having the form {A, 2) G 
SoD-G. At the same time, 42,515 activity-permission re- 
lationships were identified by IT professionals. To simplify 
this task, it was divided among the owners of the 67 ex- 
isting applications. Each owner analyzed only permissions 
related to the administered application. In this way each 
professional did not have to manage more than a thousand 
activity-permission relationships. Further, one SoD domain 
was defined for each application, since activities performed 
by different applications adopted by the organization do not 
access the same data set. Note that each identified activ- 
ity was not necessarily performed recurring to one specific 
application, namely within a single domain, but it could be 
performed within different contexts, thus spreading across 
multiple domains. 

In such a scenario, only static SoD conflicts were iden- 
tified. It was possible to deduce 4,555 illegal roles and 
4,037,051 conflicting role pairs, discarding conflicts between 
illegal and the remaining roles. As for roles, 2,566 illegal 
permissions and 1,109,541 conflicting permission pairs were 
identified, discarding conflicts between illegal and remaining 
permissions. Finally, 7,047 users were found to be perform- 
ing conflicting activities, potentially able to carry out illegal 
actions. Without the adoption of the proposed SoD model, 
such role and permission pairs should have been directly 
defined, thus requiring more effort from both the business 
and the IT staff. The results of this experimental activ- 
ity can be summarized as follows: First, defining SoD con- 
flicts through the activity concept reduced the number of 
relationships to be managed, thus leading to a reduced ad- 
ministration cost; in place of defining 4,036,908 conflicting 
role pairs and 4,402 illegal roles, the proposed SoD model 
required the definition of 437 conflicting activity pairs and 
42,515 activity-permission relationships. Second, in our SoD 
model the relationship identification task may be clearly di- 
vided among business (responsible for activity conflicts) and 
IT users (responsible for activity-permission relationships, 
further separated among application owners). In most or- 
ganizations it is unlikely the case where users can establish 
by their own all possible conflicts among roles, since this 
task requires a simultaneous good understanding of both IT 
and business requirements related to such roles. Further, 
new roles may be defined or existing roles may be reorga- 
nized without requiring new SoD constraints nor affecting 
the existing ones. 

7. CONCLUDING REMARKS 

This paper formalized a model that allows to analyze SoD 
constraints adopting a business perspective. In particular, 
potential SoD conflicts are defined among activities instead 
of roles or permissions. In this way, it is possible to de- 
fine SoD constraints in a more natural fashion, and to re- 
duce problem complexity in large-scale RBAC systems. The 
model also enables the definition of a wide taxonomy of con- 



flict types. Object-based separation of duty is introduced 
using the SoD domain concept — namely the set of data in 
which transaction conflicts may occur. Experimental results 
supported the viability of the proposed approach and con- 
firmed all the claimed benefits. 

To the best of our knowledge, this work represents the 
first attempt to address SoD from a business perspective, 
yet with an appropriate degree of formalization, that paves 
the way for further research in the area. 
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